Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RIOT POC Milestone 2 #15464

Closed
wants to merge 1 commit into from
Closed

RIOT POC Milestone 2 #15464

wants to merge 1 commit into from

Conversation

zvecr
Copy link
Member

@zvecr zvecr commented Dec 12, 2021 •
edited
Loading

Description

Raised for early visibility. Most issues fall into the same general category, RIOT isn't as clean to integrate....

Note: A fair amount of tidy up has been done in the last few weeks in preparation for later milestones.

Build system integration

RIOT build system assumes ownership of many areas. This breaks the assumption that QMK owns the process.

Right now a RIOT application stub is used to:

  1. work out config like include paths
  2. Compile riot code - including support for MODULES
  3. produce the linking of the final output

While less that ideal, it was the quickest way to get up and running.

Alternative solutions

  1. use RIOTNOLINK on the stub and handle subsequent processes ourselves
    • Extra effort to implement and maintain
  2. Modify RIOT build system?
  3. Manual everything - https://github.com/labapart/polymcu/blob/master/RTOS/RioTOS/CMakeLists.txt

RIOT config

Due to scope of M2, this currently only covers USB issues

  • To reuse RIOTs USB subsystem (duplicating is a fair amount of code to then maintain), various config options need to be coerced
    • eg VENDOR_ID -> CONFIG_USB_VID
  • Including config.h causes circular dependencies due to common_config.h pulling in core QMK code
  • Bodged right now by using CLI to gen a "clean" header with minimal content/zero dependencies.
    • Requires data driven info.json - blocks keymap level config.h overrides

API name conflicts

Currently, a few areas hit issues due to duplicate API declarations. Neither RIOT or QMK implement an effective namespacing routine to avoid this issue.

  • Timer
    • Bodged with _ prefix and macros to original names
  • i2c_master
    • Same as timer, but requires undef to then call the original functions

Future areas that will cause issue....

Other

HID subsystem

  • assumes single interface
  • duplicated and heavily modified
    • potential to target changes upstream

NRF

  • compiles but does not work

Types of Changes

  • Core
  • Bugfix
  • New feature
  • Enhancement/optimization
  • Keyboard (addition or update)
  • Keymap/layout/userspace (addition or update)
  • Documentation

Issues Fixed or Closed by This PR

Checklist

  • My code follows the code style of this project: C, Python
  • I have read the PR Checklist document and have made the appropriate changes.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • I have tested the changes and verified that they work and don't break anything (as well as I can manage).

This was referenced Mar 7, 2022
Closed
Closed
@stale
Copy link

stale bot commented Apr 17, 2022

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

@stale stale bot removed the awaiting changes label Apr 18, 2022
@PeterHindes
Copy link
Contributor

Any progress on this?

@zvecr
Copy link
Member Author

zvecr commented Dec 26, 2022

Yes

@PeterHindes
Copy link
Contributor

Is it currently possible to build ROIT for esp32-s3 boards? I want to test it.

@zvecr
Copy link
Member Author

zvecr commented Jan 16, 2023

Nope, and isn't going to be part of any initial RIOT work as its outside the scope of replacing arm_atsam platform.

@Huckies
Copy link
Contributor

Huckies commented Jan 18, 2023

Hi @zvecr

May I ask nicely, This breaks the assumption that QMK owns the process what's the point of QMK owning the whole compiling and linking even flashing progress?

As far as I can tell, QMK is nothing but an APP, it relies on the HAL to operate the actual hardware so functionalities can be achieved. For most SDKs/RTOS projects, APP is taken under control of their building system, that really makes sense because APP is the most 'Portable' part.

I'm very interested in your work, not because the new BSPs that RIOT can bring to QMK, but your attitude facing an 'modern' project. In my point of view, embedded devices should also keep pace with the times.

@zvecr
Copy link
Member Author

zvecr commented Jan 27, 2023

Closing as will be raising a much updated PR based on Milestone 6.

@zvecr zvecr closed this Jan 27, 2023
@Zawaken Zawaken mentioned this pull request Jun 28, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
cli qmk cli command core dependencies in progress keyboard python
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@zvecr @PeterHindes @Huckies @drashna